home *** CD-ROM | disk | FTP | other *** search
/ PC World Interactive 1 / PC World Interactive 1 - Nisan 1997.iso / nostalji / bbs / faq / sendmail.txt < prev    next >
Internet Message Format  |  1995-06-26  |  33KB
  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!gatech!newsxfer.itd.umich.edu!news.cic.net!locust.cic.net!pauls
  2. From: pauls@CIC.Net
  3. Newsgroups: comp.mail.sendmail,comp.mail.misc,comp.answers,news.answers
  4. Subject: comp.mail.sendmail Frequently Asked Questions (FAQ)
  5. Followup-To: comp.mail.sendmail
  6. Date: 27 Jun 1995 04:59:51 GMT
  7. Organization: CICNet, Inc.
  8. Lines: 709
  9. Approved: news-answers-request@MIT.Edu
  10. Distribution: world
  11. Expires: 08/01/95 01:00:01
  12. Message-ID: <3so387$mjn@spruce.cic.net>
  13. Reply-To: sendmail-faq@birch.ims.disa.mil (Sendmail FAQ Maintainers)
  14. NNTP-Posting-Host: locust.cic.net
  15. Summary: This posting contains a list of Frequently Asked Questions
  16.     (and their answers) about the program "sendmail", distributed
  17.     with many versions of Unix (and available for some other
  18.     operating systems).  This FAQ is shared between
  19.     comp.mail.sendmail and the Sendmail V8 distribution.  It should
  20.     be read by anyone who wishes to post to comp.mail.sendmail, or
  21.     anyone having questions about the newsgroup itself.
  22. Keywords: sendmail mail SMTP FAQ
  23. X-Posting-Frequency: posted on the 27th of each month
  24. Originator: pauls@locust.cic.net
  25. Xref: senator-bedfellow.mit.edu comp.mail.sendmail:21672 comp.mail.misc:24425 comp.answers:12729 news.answers:47113
  26.  
  27. Posted-By: auto-faq 3.1.1.2
  28. Archive-name: mail/sendmail-faq
  29.  
  30.  
  31. [The most recent copy of this document can be obtained via anonymous
  32. FTP from rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq.
  33. If you do not have access to anonymous FTP, you can retrieve it by
  34. sending email to mail-server@rtfm.mit.edu with the command "send
  35. usenet/news.answers/mail/sendmail-faq" in the message.]
  36.  
  37.  
  38.  
  39.                 comp.mail.sendmail
  40.             Frequently Asked Questions
  41.              Last updated 2 Jun 1995
  42.  
  43.  
  44. This FAQ is centered around sendmail V8 (8.6.12 being the most recent
  45. released version AFAIK, with 8.7 in early beta).  As of yet, it makes
  46. no attempt to cover other versions of sendmail in any depth, although
  47. certain other versions do get mentioned in passing.
  48.  
  49. Comments should be sent to <sendmail-faq@birch.ims.disa.mil>
  50.  
  51.  
  52. Note that much of this document is copied verbatim from the FAQ
  53. developed by Eric Allman for sendmail V8, although these two
  54. documents are continuing to diverge.  I've tried to be very careful
  55. to emulate his style and tone, so that this document has a consistent
  56. "feel" to it.  Unfortunately, I may not have completely succeeded and
  57. where he may have been succint, I may have come across as terse (or
  58. worse).
  59.  
  60. I apologize in advance for anyone who is offended, but this document
  61. is currently targeted towards the experienced Unix System
  62. Administrator/Domain Administrator/Postmaster, and therefore much has
  63. been omitted in the interest of brevity (perhaps too much, at least
  64. on my part).
  65.  
  66. With several major overhauls scheduled (including at least one
  67. complete re-write), this situation will hopefully improve
  68. dramatically, but you have to bear with me for the nonce.
  69.  
  70.     -Brad Knowles
  71.      comp.mail.sendmail FAQ Coordinator
  72.  
  73.  
  74. ======================================================================
  75. BEFORE YOU GO ANY FURTHER
  76. ======================================================================
  77.  
  78.   * What do you wish everyone would do before sending you mail or
  79.     posting to comp.mail.sendmail?
  80.  
  81.     Read this FAQ completely.  If they're posting a question
  82.     about Sendmail V8, read src/READ_ME and cf/README
  83.     completely.  Read the books written to help with common
  84.     problems such as compilation and installation, configuration,
  85.     security issues, etc....  Ask themselves if their question
  86.     hasn't already been answered.
  87. ----------------------------------------------------------------------
  88.   * How can I be sure if this is the right place to look for answers
  89.     to my questions?
  90.  
  91.     1. Do you know, for a fact, that the question is related to
  92.        the Unix program "sendmail"?
  93.  
  94.     2. Is the question about a sendmail-like program (e.g.,
  95.        Smail, Zmailer, MMDF, etc...)?
  96.  
  97.     3. Is the question about an SMTP Gateway product for a LAN
  98.        mail package (e.g., cc:Mail, MS-Mail, WordPerfect
  99.        Office/GroupWise, etc...) or a POP/IMAP client program
  100.        (e.g., Eudora, Pegasus, Z-Mail, etc...)?
  101.  
  102.     If you answered "yes" to the question #1, then this is the
  103.     right place.
  104.  
  105.     If you're not using the most recent version of sendmail V8,
  106.     be prepared for a lot of answers that amount to "Get V8".  V8
  107.     doesn't solve every single sendmail problem that exists
  108.     (properly configured or not), but it is the area of heaviest
  109.     current development and solves a long laundry list of
  110.     problems that previous versions of sendmail have.
  111.  
  112.     If you answered "yes" to question #2 and are not going to
  113.     upgrade to sendmail (presumably V8), then this is probably
  114.     not the right place to look.  I recommend looking elsewhere
  115.     in the "comp.mail.*" hierarchy and seeing if there is a
  116.     newsgroup that might be more appropriate (comp.mail.smail,
  117.     comp.mail.misc, etc...).
  118.  
  119.     If you answered "yes" to question #3, then this is certainly
  120.     not the right place to look.  Look around elsewhere in the
  121.     "comp.mail.*"  or "comp.*" hierarchy for a more appropriate
  122.     newsgroup.  You may also find some useful information in
  123.     ftp://rtfm.mit.edu:/pub/usenet/news.answers/mail/mailclients-faq
  124.     (put together by Paul Southworth from various sources on
  125.     comp.mail.misc).  Note that Z-Mail now has it's own
  126.     newsgroup, comp.mail.zmail.
  127.  
  128.     If you couldn't answer "yes" to any of the above questions,
  129.     then you're DEFINITELY in the wrong place.  For the sake of
  130.     your sanity and ego, not to mention avoiding the waste of
  131.     your time and ours, try asking your System or E-Mail
  132.     Administrator(s) before you post any questions publicly.
  133. ----------------------------------------------------------------------
  134.   * Where can I find the latest version of this FAQ?
  135.  
  136.     The most recent version is available via anonymous ftp to
  137.     rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq.
  138.     If you do not have access to anonymous FTP, you can retrieve
  139.     it by sending email to mail-server@rtfm.mit.edu with the
  140.     command "send usenet/news.answers/mail/sendmail-faq" in the
  141.     message.
  142. ----------------------------------------------------------------------
  143.   * I don't have access to Usenet news.  Can I still get access to
  144.     comp.mail.sendmail?
  145.  
  146.     Yes.  Send email to mxt@dl.ac.uk with the command "sub
  147.     comp-news.comp.mail.sendmail <full-US-ordered-email-address>"
  148.     in the message.
  149.  
  150.     E-mail you want posted on comp.mail.sendmail should be sent
  151.     to comp-mail-sendmail@dl.ac.uk
  152. ----------------------------------------------------------------------
  153.   * I have sendmail-related DNS questions.  Where should I ask them?
  154.  
  155.     Depending on how deeply they get into the DNS, they can be
  156.     asked here.  However, you'll probably be told that you should
  157.     send them to the Info-BIND mailing list (if the question is
  158.     specific to that program) or to the Usenet newsgroup
  159.     comp.protocols.tcp-ip.domains (DNS in general).
  160. ----------------------------------------------------------------------
  161.   * How do I subscribe to either of these?
  162.  
  163.     For comp.protocols.tcp-ip.domains, you have to be on Usenet.
  164.     So far as we know, they don't have a news-to-mail gateway
  165.     yet.  They do have a FAQ, and it can be found at
  166.     <URL:ftp://ftp.njit.edu/pub/dns/Comp.protocols.tcp-ip.domains.FAQ>
  167.  
  168.     For the Info-BIND mailing list, send email to
  169.     bind-request@uunet.uu.net with the command "subscribe" in the
  170.     message.  Submissions should be sent to bind@uunet.uu.net
  171.  
  172. ======================================================================
  173. TO DO (in no particular order)
  174. ======================================================================
  175. Table of Contents
  176. Restructure content (outline format)
  177. Index
  178. Additional net resources (web pages, anonymous ftp sites, etc...)
  179. Annotated bibliography (including RFCs and comments/corrections for
  180.     books specific to sendmail)
  181. Reorganize by platform/version of sendmail (All Sun questions in one
  182.     section, all AIX questions in another, etc...)
  183.  
  184. ======================================================================
  185. GENERAL QUESTIONS
  186. ======================================================================
  187.  
  188.   * Where can I get Version 8?
  189.  
  190.     Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail.
  191. ----------------------------------------------------------------------
  192.   * What are the differences between Version 8 and other versions?
  193.  
  194.     See doc/changes/changes.me in the sendmail V8 distribution.
  195. ----------------------------------------------------------------------
  196.   * What books are available describing sendmail?
  197.  
  198.     There are two books available devoted to sendmail:
  199.  
  200.         Costales, Allman, and Rickert, _Sendmail_.  O'Reilly &
  201.         Associates.
  202.  
  203.         Avolio & Vixie, _Sendmail: Theory and Practice_.  Digital
  204.         Press.
  205.  
  206.     Several books have sendmail chapters, for example:
  207.  
  208.         Nemeth, Snyder, and Seebass, _Unix System Administration
  209.         Handbook_.  Prentice-Hall.
  210.         Carl-Mitchell and Quarterman, _Practical Internetworking with
  211.         TCP/IP and UNIX_.  Addison-Wesley.
  212.         Hunt, _TCP/IP Network Administration_.  O'Reilly & Associates.
  213.  
  214.     For details on sendmail-related DNS issues, consult:
  215.  
  216.         Liu and Albitz, _DNS and BIND_.  O'Reilly & Associates.
  217.  
  218.     For details on UUCP, see:
  219.  
  220.         O'Reilly and Todino, _Managing UUCP and Usenet_.
  221.         O'Reilly & Associates.
  222.  
  223. ======================================================================
  224. CONFIGURATION QUESTIONS (V8 unless otherwise indicated)
  225. ======================================================================
  226.  
  227.   * How do I make all my addresses appear to be from a single host?
  228.  
  229.     Using the m4 macros, use:
  230.  
  231.         MASQUERADE_AS(my.dom.ain)
  232.  
  233.     This will cause all addresses to be sent out as being from
  234.     the indicated domain.
  235.  
  236.     On your mailhub/mailhost/Domain Mail eXchanger, you may need
  237.     to add "my.dom.ain" to the sendmail.cw file or the
  238.     "Cwhost.my.dom.ain" line in the sendmail.cf file.
  239. ----------------------------------------------------------------------
  240.   * How do I rewrite my From: lines to read ``First_Last@My.Domain''?
  241.  
  242.     There are a couple of ways of doing this.  This describes
  243.     using the "user database" code.  This is still experimental,
  244.     and was intended for a different purpose -- however, it does
  245.     work with a bit of care.  It does require that you have the
  246.     Berkeley "db" package installed (it won't work with DBM).
  247.  
  248.     First, create your input file.  This should have lines like:
  249.  
  250.         loginname:mailname    First_Last
  251.         First_Last:maildrop    loginname
  252.  
  253.     Install it in (say) /etc/userdb.  Create the database:
  254.  
  255.         makemap btree /etc/userdb.db < /etc/userdb
  256.  
  257.     You can then create a config file that uses this.  You will
  258.     have to include the following in your .mc file:
  259.  
  260.         define(confUSERDB_SPEC, /etc/userdb.db)
  261.         FEATURE(notsticky)
  262. ----------------------------------------------------------------------
  263.   * So what was the user database feature intended for?
  264.  
  265.     The intent was to have all information for a given user
  266.     (where the user is the unique login name, not an inherently
  267.     non-unique full name) in one place.  This would include phone
  268.     numbers, addresses, and so forth.  The "maildrop" feature is
  269.     because Berkeley does not use a centralized mail server
  270.     (there are a number of reasons for this that are mostly
  271.     historic), and so we need to know where each user gets his or
  272.     her mail delivered -- i.e., the mail drop.
  273.  
  274.     We are in the process of setting up our environment so that
  275.     mail sent to an unqualified "name" goes to that person's
  276.     preferred maildrop; mail sent to "name@host" goes to that
  277.     host.  The purpose of "FEATURE(notsticky)" is to cause
  278.     "name@host" to be looked up in the user database for delivery
  279.     to the maildrop.
  280. ----------------------------------------------------------------------
  281.   * Why are you so hostile to using full names for e-mail addresses?
  282.  
  283.     Because full names are not unique.  For example, the computer
  284.     community has two Andy Tannenbaums and two Peter Deutsches.
  285.     At one time, Bell Labs had two Stephen R. Bournes with
  286.     offices a few doors apart.  You can create alternative
  287.     addresses (e.g., Stephen_R_Bourne_2), but that's even worse
  288.     -- which one of them has to have their name desecrated in
  289.     this way?  And you can bet that one of them will get most of
  290.     the other person's e-mail.
  291.  
  292.     So called "full names" are just an attempt to create longer
  293.     versions of unique names.  Rather that lulling people into a
  294.     sense of security, I'd rather that it be clear that these
  295.     handles are arbitrary.  People should use good user agents
  296.     that have alias mappings so that they can attach arbitrary
  297.     names for their personal use to those with whom they
  298.     correspond (such as the MH alias file).
  299.  
  300.     Even worse is fuzzy matching in e-mail -- this can make good
  301.     addresses turn bad.  For example, Eric Allman is currently
  302.     (to the best of our knowledge) the only ``Allman'' at
  303.     Berkeley, so mail sent to "Allman@Berkeley.EDU" should get to
  304.     him.  But if another Allman ever appears, this address could
  305.     suddenly become ambiguous.  He's been the only Allman at
  306.     Berkeley for over fifteen years -- to suddenly have this
  307.     "good address" bounce mail because it is ambiguous would be a
  308.     heinous wrong.
  309.  
  310.     Finger services should be as fuzzy as possible (within
  311.     reason, of course).  Mail services should be unique.
  312. ----------------------------------------------------------------------
  313.   * Should I use a wildcard MX for my domain?
  314.  
  315.     If at all possible, no.
  316.  
  317.     Wildcard MX records have lots of semantic "gotcha"s.  For
  318.     example, they will match a host "unknown.your.domain" -- if
  319.     you don't explicitly test for unknown hosts in your domain,
  320.     you will get "config error: mail loops back to myself"
  321.     errors.
  322.  
  323.     See RFCs 1535-1537 for more detail and other related (or
  324.     common) problems.
  325. ----------------------------------------------------------------------
  326.   * How can I get sendmail to process messages sent to an account and
  327.     send the results back to the originator?
  328.  
  329.     This is a local mailer issue, not a sendmail issue.
  330.     Depending on what you're doing, look at procmail (mentioned
  331.     again below), ftpmail, or Majordomo.
  332.  
  333.     Check your local archie server to see what machine(s) nearest
  334.     you have the most recent versions of these programs.
  335. ----------------------------------------------------------------------
  336.   * How can I get sendmail to deliver local mail to $HOME/.mail
  337.     instead of into /usr/spool/mail (or /usr/mail)?
  338.  
  339.     Again, this is a local mailer issue, not a sendmail issue.
  340.     Either modify your local mailer (source code will be
  341.     required) or change the program called in the "local" mailer
  342.     configuration description to be a new program that does this
  343.     local delivery.  One program that is capable of doing this is
  344.     "procmail", although there are probably many others as well.
  345.  
  346.     You might be interested in reading the paper ``HLFSD:
  347.     Delivering Email to your $HOME'' available in the Proceedings
  348.     of the USENIX System Administration (LISA VII) Conference
  349.     (November 1993).  This is also available via public FTP from
  350.     ftp.cs.columbia.edu in /pub/hlfsd/{README.hlfsd,hlfsd.ps}.
  351. ----------------------------------------------------------------------
  352.   * I'm trying to to get my mail to go into queue only mode, and it
  353.     delivers the mail interactively anyway.  (Or, I'm trying to use
  354.     the "don't deliver to expensive mailer" flag, and it delivers the
  355.     mail interactively anyway.)  I can see it does it:  here's the
  356.     output of "sendmail -v foo@somehost" (or Mail -v or equivalent).
  357.  
  358.     The -v flag to sendmail (which is implied by the -v flag to
  359.     Mail and other programs in that family) tells sendmail to
  360.     watch the transaction.  Since you have explicitly asked to
  361.     see what's going on, it assumes that you do not want to to
  362.     auto-queue, and turns that feature off.  Remove the -v flag
  363.     and use a "tail -f" of the log instead to see what's going
  364.     on.
  365.  
  366.     If you are trying to use the "don't deliver to expensive
  367.     mailer" flag (mailer flag "e"), be sure you also turn on
  368.     global option "c" -- otherwise it ignores the mailer flag.
  369. ----------------------------------------------------------------------
  370.   * There are four UUCP mailers listed in the configuration files.
  371.     Which one should I use?
  372.  
  373.     The choice is partly a matter of local preferences and what
  374.     is running at the other end of your UUCP connection.  Unlike
  375.     good protocols that define what will go over the wire, UUCP
  376.     uses the policy that you should do what is right for the
  377.     other end; if they change, you have to change.  This makes it
  378.     hard to do the right thing, and discourages people from
  379.     updating their software.  In general, if you can avoid UUCP,
  380.     please do.
  381.  
  382.     If you can't avoid it, you'll have to find the version that
  383.     is closest to what the other end accepts.  Following is a
  384.     summary of the UUCP mailers available.
  385.  
  386.     uucp-old (obsolete name: "uucp")
  387.       This is the oldest, the worst (but the closest to UUCP) way
  388.       of sending messages across UUCP connections.  It does
  389.       bangify everything and prepends $U (your UUCP name) to the
  390.       sender's address (which can already be a bang path
  391.       itself).  It can only send to one address at a time, so it
  392.       spends a lot of time copying duplicates of messages.  Avoid
  393.       this if at all possible.
  394.  
  395.     uucp-new (obsolete name: "suucp")
  396.       The same as above, except that it assumes that in one rmail
  397.       command you can specify several recipients.  It still has a
  398.       lot of other problems.
  399.  
  400.     uucp-dom
  401.       This UUCP mailer keeps everything as domain addresses.
  402.       Basically, it uses the SMTP mailer rewriting rules.
  403.  
  404.       Unfortunately, a lot of UUCP mailer transport agents
  405.       require bangified addresses in the envelope, although you
  406.       can use domain-based addresses in the message header.  (The
  407.       envelope shows up as the From_ line on UNIX mail.)  So....
  408.  
  409.     uucp-uudom
  410.       This is a cross between uucp-new (for the envelope
  411.       addresses) and uucp-dom (for the header addresses).  It
  412.       bangifies the envelope sender (From_ line in messages)
  413.       without adding the local hostname, unless there is no host
  414.       name on the address at all (e.g., "wolf") or the host
  415.       component is a UUCP host name instead of a domain name
  416.       ("somehost!wolf" instead of "some.dom.ain!wolf").
  417.  
  418.     Examples:
  419.  
  420.     We are on host grasp.insa-lyon.fr (UUCP host name "grasp").
  421.     The following summarizes the sender rewriting for various
  422.     mailers.
  423.  
  424.     Mailer          sender        rewriting in the envelope
  425.     ------        ------        -------------------------
  426.     uucp-{old,new}    wolf        grasp!wolf
  427.     uucp-dom    wolf        wolf@grasp.insa-lyon.fr
  428.     uucp-uudom    wolf        grasp.insa-lyon.fr!wolf
  429.  
  430.     uucp-{old,new}    wolf@fr.net    grasp!fr.net!wolf
  431.     uucp-dom    wolf@fr.net    wolf@fr.net
  432.     uucp-uudom    wolf@fr.net    fr.net!wolf
  433.  
  434.     uucp-{old,new}    somehost!wolf    grasp!somehost!wolf
  435.     uucp-dom    somehost!wolf    somehost!wolf@grasp.insa-lyon.fr
  436.     uucp-uudom    somehost!wolf    grasp.insa-lyon.fr!somehost!wolf
  437.  
  438. ======================================================================
  439. RESOLVING PROBLEMS (V8 unless otherwise specified)
  440. ======================================================================
  441.  
  442.   * When I compile, I get "undefined symbol inet_aton" and "undefined
  443.     symbol _strerror" messages.
  444.  
  445.     You've probably replaced your resolver with the version from
  446.     BIND 4.9.3.  You need to compile with -l44bsd in order to get
  447.     the additional routines.
  448. ----------------------------------------------------------------------
  449.   * I'm getting "Local configuration error" messages, such as:
  450.  
  451.     553 relay.domain.net config error: mail loops back to myself
  452.     554 <user@domain.net>... Local configuration error
  453.  
  454.     How can I solve this problem?
  455.  
  456.     You have asked mail to the domain (e.g., domain.net) to be
  457.     forwarded to a specific host (in this case, relay.domain.net)
  458.     by using an MX record, but the relay machine doesn't
  459.     recognize itself as domain.net.  Add domain.net to
  460.     /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or
  461.     add "Cw domain.net" to your configuration file.
  462.  
  463.     IMPORTANT:  Be sure you kill and restart the sendmail daemon
  464.     after you change the configuration file (for ANY change in
  465.     the configuration, not just this one):
  466.  
  467.         kill `head -1 /etc/sendmail.pid`
  468.         sh -c "`tail -1 /etc/sendmail.pid`"
  469.  
  470.     NOTA BENE:  kill -1 does not work!
  471. ----------------------------------------------------------------------
  472.   * When I use sendmail V8 with a Sun config file I get lines like:
  473.  
  474.     /etc/sendmail.cf: line 273: replacement $3 out of bounds
  475.  
  476.     the line in question reads:
  477.  
  478.     R$*<@$%y>$*        $1<@$2.LOCAL>$3            user@ether
  479.  
  480.     what does this mean?  How do I fix it?
  481.  
  482.     V8 doesn't recognize the Sun "$%y" syntax, so as far as it is
  483.     concerned, there is only a $1 and a $2 (but no $3) in this
  484.     line.  Read Rick McCarty's paper on "Converting Standard Sun
  485.     Config Files to Sendmail Version 8", in the contrib directory
  486.     (file "converting.sun.configs") in the latest sendmail V8
  487.     distribution for a full discussion of how to do this.
  488. ----------------------------------------------------------------------
  489.   * When I use sendmail V8 on a Sun, I sometimes get lines like:
  490.  
  491.     /etc/sendmail.cf: line 445: bad ruleset 96 (50 max)
  492.  
  493.     what does this mean?  How do I fix it?
  494.  
  495.     You're somehow trying to start up the old Sun sendmail (or
  496.     sendmail.mx) with a sendmail V8 config file, which Sun's
  497.     sendmail doesn't like.  Check your /etc/rc.local, any
  498.     procedures that have been created to stop and re-start the
  499.     sendmail processes, etc....  Make sure that you've switched
  500.     everything over to using the new sendmail.  To keep this
  501.     problem from ever happening again, try the following:
  502.  
  503.         mv /usr/lib/sendmail /usr/lib/sendmail.old
  504.         ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail
  505.         mv /usr/lib/sendmail.mx /usr/lib/sendmail.mx.old
  506.         ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail.mx
  507.         chmod 0000 /usr/lib/sendmail.old
  508.         chmod 0000 /usr/lib/sendmail.mx.old
  509.  
  510.     Assuming you have installed sendmail V8 in /usr/local/lib.
  511. ----------------------------------------------------------------------
  512.   * When I use sendmail V8 on an IBM RS/6000 running AIX, the system
  513.     resource controller always reports sendmail as "inoperative" even
  514.     though it is running.  What's wrong?
  515.  
  516.     When running as a daemon, sendmail detaches from its parent
  517.     process, fooling the SRC into thinking that sendmail has
  518.     exited.  To fix this, issue the commands:
  519.  
  520.         kill `head -1 /etc/sendmail.pid`
  521.         chssys -s sendmail -f 9 -n 15 -S -a "-d0.1"
  522.         startsrc -s sendmail -a "-bd -q30m"
  523.         # your sendmail args may vary
  524.  
  525.     Now the SRC should report the correct status of sendmail.  A
  526.     side-effect of the "-d0.1" option is that a few lines of
  527.     debug output will be printed on the system console every time
  528.     sendmail starts up.
  529.  
  530.     For more information, read up on the System Resource
  531.     Controller, the lssrc command and the chssys command in the
  532.     online documentation.
  533. ----------------------------------------------------------------------
  534.   * When I use sendmail V8 on an Intel x86 machine running Linux, I
  535.     have some problems.  Specifically....
  536.  
  537.     The current versions of Linux are generally considered to be
  538.     great for hobbyists and anyone else who wants to learn Unix
  539.     inside and out, or wants to always have something to do, or
  540.     wants a machine for light-duty mostly personal use and not
  541.     high-volume multi-user purposes.
  542.  
  543.     However, for those who want a system that will just sit in
  544.     the background and work without a fuss handling thousands of
  545.     mail messages a day for lots of different users, it's not
  546.     (yet) stable enough to fit the bill.
  547.  
  548.     Unfortunately, there are no known shareware/freeware
  549.     implementations of any operating system that provides the
  550.     level of stability necessary to handle that kind of load
  551.     (i.e., there are no free lunches).
  552.  
  553.     If you're wedded to the Intel x86 platform and want to run
  554.     sendmail, we suggest you look at commercial implementations
  555.     of Unix such as Interactive, UnixWare, Solaris, or BSD/386
  556.     (just a sample of the dozens of different versions of Unix
  557.     for Intel x86).
  558.  
  559.     Of all known vendor supported versions of Unix for Intel x86,
  560.     BSDI's BSD/386 is least expensive and the only one known to
  561.     currently ship with sendmail V8 pre-installed.  Since sendmail
  562.     V8 is continuing to be developed at UC Berkeley, and BSD/386
  563.     is a full BSD 4.4 implementation, this is obviously be the most
  564.     "native" sendmail V8 environment.
  565. ----------------------------------------------------------------------
  566.   * When I use sendmail on an Intel x86 machine running OS/2, I have
  567.     some problems.  Specifically, I have....
  568.  
  569.     The OS/2 port of sendmail is known to have left out huge
  570.     chunks of the code and functionality of even much older
  571.     versions of sendmail, in large part because the underlying OS
  572.     just doesn't have the necessary hooks to make it happen.
  573.     This port is so broken that we make no attempt to provide any
  574.     kind of support for it.  Try BSDI's BSD/386 instead.
  575. ----------------------------------------------------------------------
  576.   * I'm connected to the network via a SLIP/PPP link.  Sometimes my
  577.     sendmail process hangs (although it looks like part of the
  578.     message has been transfered).  Everything else works.  What's
  579.     wrong?
  580.  
  581.     Most likely, the problem isn't sendmail at all, but the low
  582.     level network connection.  It's important that the MTU
  583.     (Maximum Transfer Unit) for the SLIP connection be set
  584.     properly at both ends.  If they disagree, large packets will
  585.     be trashed and the connection will hang.
  586. ----------------------------------------------------------------------
  587.   * I just upgraded to 8.x and suddenly I'm getting messages in my
  588.     syslog of the form "collect: I/O error on connection".  What is
  589.     going wrong?
  590.  
  591.     Nothing.  This is just a diagnosis of a condition that had
  592.     not been diagnosed before.  If you are getting a lot of these
  593.     from a single host, there is probably some incompatibility
  594.     between 8.x and that host.  If you get a lot of them in
  595.     general, you may have network problems that are causing
  596.     connections to get reset.
  597. ----------------------------------------------------------------------
  598.   * I just upgraded to 8.x and now when my users try to forward their
  599.     mail to a program they get an "illegal shell" message and their
  600.     mail is not delivered.  What's wrong?
  601.  
  602.     In order for people to be able to run a program from their
  603.     .forward file, 8.x insists that their shell (that is, the
  604.     shell listed for that user in the passwd entry) be a "valid"
  605.     shell, meaning a shell listed in /etc/shells.  If /etc/shells
  606.     does not exist, a default list is used, typically consisting
  607.     of /bin/sh and /bin/csh.
  608.  
  609.     This is to support environments that may have NFS-shared
  610.     directories mounted on machines on which users do not have
  611.     login permission.  For example, many people make their
  612.     file server inaccessible for performance or security
  613.     reasons; although users have directories, their shell on
  614.     the server is /usr/local/etc/nologin or some such.  If you
  615.     allowed them to run programs anyway you might as well let
  616.     them log in.
  617.  
  618.     If you are willing to let users run programs from their
  619.     .forward file even though they cannot telnet or rsh in (as
  620.     might be reasonable if you run smrsh to control the list of
  621.     programs they can run) then add the line
  622.  
  623.         /SENDMAIL/ANY/SHELL/
  624.  
  625.     to /etc/shells.  This must be typed exactly as indicated,
  626.     in caps, with the trailing slash.  NOTA BENE:  DO NOT
  627.     list /usr/local/etc/nologin in /etc/shells -- this will
  628.     open up other security problems.
  629. ----------------------------------------------------------------------
  630.   * I just upgraded to 8.x and suddenly connections to the SMTP port
  631.     take a long time.  What is going wrong?
  632.  
  633.     It's probably something weird in your TCP implementation that
  634.     makes the IDENT code act oddly.  On most systems V8 tries to
  635.     do a ``callback'' to the connecting host to get a validated
  636.     user name (see RFC 1413 for detail).  If the connecting host
  637.     does not support such a service it will normally fail quickly
  638.     with "Connection refused", but certain kinds of packet
  639.     filters and certain TCP implementations just time out.
  640.  
  641.     To test this, set the IDENT timeout to zero using:
  642.  
  643.         define(`confREAD_TIMEOUT',`Ident=0')dnl
  644.  
  645.     in the .mc file used by m4 to generate your sendmail.cf
  646.     file.  Alternatively, if you don't use m4, you can put
  647.     ``OrIdent=0'' in the configuration file (we recommend the m4
  648.     solution, since that makes maintenance much easier for people
  649.     who don't understand sendmail re-write rules, or after you've
  650.     been away from it for a while).  Either way, this will
  651.     completely disable all use of the IDENT protocol.
  652.  
  653.     Another possible problem is that you have your name server
  654.     and/or resolver configured improperly.  Make sure that all
  655.     "nameserver" entries in /etc/resolv.conf point to functional
  656.     servers.  If you are running your own server make certain
  657.     that all the servers listed in your root cache (usually
  658.     called something like "/var/namedb/root.cache"; see your
  659.     /etc/named.boot file to get your value) are up to date.
  660.     Either of these can cause long delays.
  661. ----------------------------------------------------------------------
  662.   * I just upgraded to 8.x and suddenly I get errors such as ``unknown
  663.     mailer error 5 -- mail: options MUST PRECEDE recipients.''  What is
  664.     going wrong?
  665.  
  666.     You need OSTYPE(systype) in your .mc file -- otherwise the
  667.     configurations use a default that probably disagrees with
  668.     your local mail system.  See cf/README for details.
  669. ----------------------------------------------------------------------
  670.   * Under V8, the "From " header gets mysteriously munged when I send
  671.     to an alias.
  672.  
  673.     ``It's not a bug, it's a feature.''  This happens when you
  674.     have a "owner-list" alias and you send to "list".  V8
  675.     propagates the owner information into the envelope sender
  676.     field (which appears as the "From " header on UNIX mail or as
  677.     the Return-Path: header) so that downstream errors are
  678.     properly returned to the mailing list owner instead of to the
  679.     sender.  In order to make this appear as sensible as possible
  680.     to end users, I recommend making the owner point to a
  681.     "request" address -- for example:
  682.  
  683.         list:        :include:/path/name/list.list
  684.         owner-list:    list-request
  685.         list-request:    eric
  686.  
  687.     This will make message sent to "list" come out as being "From
  688.     list-request" instead of "From eric".
  689. ----------------------------------------------------------------------
  690.   * I am trying to use MASQUERADE_AS (or the user database) to
  691.     rewrite from addresses, and although it works in the From: header
  692.     line, it doesn't work in the envelope (e.g., the "From " line).
  693.  
  694.     Believe it or not, this is intentional.  The interpretation
  695.     of the standards by the V8 development group was that this
  696.     was an inappropriate rewriting, and that if the rewriting
  697.     were incorrect at least the envelope would contain a valid
  698.     return address.  Other people have since described scenarios
  699.     where the envelope cannot be correct without this rewriting,
  700.     so 8.7 will have an option to rewrite both header and
  701.     envelope.
  702. ----------------------------------------------------------------------
  703.   * I want to run Sendmail version 8 on my DEC system, but you don't
  704.     have MAIL11V3 support in sendmail.  How do I handle this?
  705.  
  706.     Get the reimplementation of the mail11 protocol by Keith
  707.     Moore from gatekeeper.dec.com in /pub/DEC/gwtools (with
  708.     contributions from Paul Vixie).
  709.  
  710.     Rumour has it that Paul will be fully integrating into
  711.     sendmail V8 what little is left of IDA sendmail that is not
  712.     handled (or handled as well) by V8.  No additional
  713.     information on this project is currently available.
  714. ----------------------------------------------------------------------
  715.   * Messages seem to disappear from my queue unsent.  When I look in
  716.     the queue directory I see that they have been renamed from qf* to
  717.     Qf*, and sendmail doesn't see these.
  718.  
  719.     If you look closely you should find that the Qf files are
  720.     owned by users other than root.  Since sendmail runs as root
  721.     it refuses to believe information in non-root-owned qf files,
  722.     and it renames them to Qf to get them out of the way and make
  723.     it easy for you to find.  The usual cause of this is
  724.     twofold:  first, you have the queue directory world writable
  725.     (which is probably a mistake -- this opens up other security
  726.     problems) and someone is calling sendmail with an "unsafe"
  727.     flag, usually a -o flag that sets an option that could
  728.     compromise security.  When sendmail sees this it gives up
  729.     setuid root permissions.
  730.  
  731.     The usual solution is to not use the problematic flags.  If
  732.     you must use them, you have to write a special queue
  733.     directory and have them processed by the same uid that
  734.     submitted the job in the first place.
  735. ----------------------------------------------------------------------
  736.